#288941 - 26/10/2006 17:55
JEmplode "ethernet broadcase" discovery protocol bug?
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Hi,
It is really rare that JEmplode can automatically discover empegs on my LAN. I nearly always have to enter a "specific address" (eg. 10.0.0.8) to get it to find/connect to a player.
Today, whilst experimenting with Kubuntu Edgy, I ran Wireshark (aka. "ethereal") while trying JEmplode, and found that the UDP discovery packets it sends (for the "ethernet broadcast" option) are reported as having invalid packet checksums.
That's gotta be a JEmplode (or java?) bug, and I wonder if that's why my empegs never seem to respond.. ??
???
|
|
Top
|
|
|
|
|
#288942 - 26/10/2006 18:12
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Ahh.. ignore the "bad checksum" stuff -- that seems to have come as a result of running wireshark on the same machine as JEmplode, where the checksum is inserted by the hardware upon actual transmission. So that's not the problem. I wonder what is?
Cheers
|
|
Top
|
|
|
|
|
#288943 - 26/10/2006 18:19
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
I had the same problem when writing the FindEmpeg utility way back then. Never investigated it too much. For some people it'd work but for others it wouldn't.
|
|
Top
|
|
|
|
|
#288944 - 26/10/2006 19:38
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: tman]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Well, I've dug out my ancient 10mb/sec shared hub, and plugged everybody together into that for more predictable behaviour.
Sending a "ping" to the empeg after power-on now works on the very first attempt. Normally, with all connected to the 10/100 switch here, the first three pings don't get answered. I suppose this means it's due to the switch undergoing some kind of learning period before it passes packets to its internal 10mb/s lan from the 100mb/s side.
Still no luck with the discovery packets.
Those are using uPNP multicasting, and the empeg's SMC ethernet interrupt handler never sees them, even though everyone else on the same hub/switch can see them.
I guess in theory this means it should NEVER work. But I know it has worked here on occasion in the past, though not with this version of JEmplode (or maybe only with Emplode.. mmm.. gotta try that now).
Cheers
|
|
Top
|
|
|
|
|
#288945 - 26/10/2006 19:45
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Ahhhh..
Okay, I just traced what Emplode does. It sends completely different discovery broadcast packets, compared with JEmplode. And Emplode actually finds the empeg.
So, somehow JEmplode just has the wrong discovery protocol altogether.
Does anyone out there know how to rebuild JEmplode from sources? If so, then we can fix this.
Cheers
|
|
Top
|
|
|
|
|
#288946 - 26/10/2006 20:05
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
Okay, I just traced what Emplode does. It sends completely different discovery broadcast packets, compared with JEmplode. And Emplode actually finds the empeg.
So, somehow JEmplode just has the wrong discovery protocol altogether.
Ah, that makes a certain amount of sense. Jemplode is sort-of the same thing as Rio Music Manager Light, aimed at the Rio Karma... and you do indeed find Karmas using UPnP-style (actually SSDP) multicasting. The Empeg, on the other hand, was invented before SSDP was and uses a custom protocol. Maybe the most recent Jemplode build accidentally has the Karma discovery code enabled and not the Empeg discovery code?
SSDP discovery was slated to be added to car-player v3 software, but never made it beyond the experimental stage.
Peter
|
|
Top
|
|
|
|
|
#288947 - 26/10/2006 20:51
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
Quote:
Okay, I just traced what Emplode does. It sends completely different discovery broadcast packets, compared with JEmplode. And Emplode actually finds the empeg.
So, somehow JEmplode just has the wrong discovery protocol altogether.
Ah, that makes a certain amount of sense. Jemplode is sort-of the same thing as Rio Music Manager Light, aimed at the Rio Karma... and you do indeed find Karmas using UPnP-style (actually SSDP) multicasting. The Empeg, on the other hand, was invented before SSDP was and uses a custom protocol. Maybe the most recent Jemplode build accidentally has the Karma discovery code enabled and not the Empeg discovery code?
SSDP discovery was slated to be added to car-player v3 software, but never made it beyond the experimental stage.
Peter
Yup, that all makes sense -- the IP address and port matches the Karma discovery.
Mmm.. I suppose I could just have Hijack listen/respond to those requests, if I knew what the correct response was supposed to be.
But it's probably simpler (ha!) to try and get JEmplode rebuilt with the correct protocol enabled.
Cheers
|
|
Top
|
|
|
|
|
#288948 - 26/10/2006 21:00
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
pooh-bah
Registered: 06/04/2005
Posts: 2026
Loc: Seattle transplant
|
Quote:
But it's probably simpler (ha!) to try and get JEmplode rebuilt with the correct protocol enabled.
Cheers
Would that then be jEmplode v69.0000000000000000002
or jEmplode v69.0000000000000000001b?
/i'm a source control noob
_________________________
10101311 (20GB- backup empeg)
10101466 (2x60GB, Eutronix/GreenLights Blue) (Stolen!)
|
|
Top
|
|
|
|
|
#288949 - 26/10/2006 21:15
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: Robotic]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
Quote:
But it's probably simpler (ha!) to try and get JEmplode rebuilt with the correct protocol enabled.
Cheers
Would that then be jEmplode v69.0000000000000000002
or jEmplode v69.0000000000000000001b?
/i'm a source control noob
All of these: v69, v69.0000...0001, and v70.
I don't know about the two versions you listed (obtained from where?)
|
|
Top
|
|
|
|
|
#288950 - 26/10/2006 21:26
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
pooh-bah
Registered: 06/04/2005
Posts: 2026
Loc: Seattle transplant
|
Quote:
I don't know about the two versions you listed (obtained from where?)
Just joshin', Mark.
I was supposing what the version following 69.000...0001 would be called.
_________________________
10101311 (20GB- backup empeg)
10101466 (2x60GB, Eutronix/GreenLights Blue) (Stolen!)
|
|
Top
|
|
|
|
|
#288951 - 27/10/2006 04:43
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 10/06/1999
Posts: 5916
Loc: Wivenhoe, Essex, UK
|
Quote:
Does anyone out there know how to rebuild JEmplode from sources? If so, then we can fix this.
Do we actually have the source ? Every time I have been to the JEmplode site the source link has taken me to a 404 page.
_________________________
Remind me to change my signature to something more interesting someday
|
|
Top
|
|
|
|
|
#288952 - 27/10/2006 12:29
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
The last time I looked at this, the problem was that jEmplode was sending out guesses as to the broadcast address because Java doesn't have hooks low enough in the OS in order to find the real broadcast address. On several of my networks, its guesses were wrong. Are you sure that's not your problem?
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#288953 - 27/10/2006 13:00
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: wfaulk]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
The last time I looked at this, the problem was that jEmplode was sending out guesses as to the broadcast address because Java doesn't have hooks low enough in the OS in order to find the real broadcast address. On several of my networks, its guesses were wrong. Are you sure that's not your problem?
Quite positive, thanks.
It's simply using the Karma protocol rather than the Empeg protocol.
|
|
Top
|
|
|
|
|
#288954 - 02/11/2006 06:41
Re: JEmplode "ethernet broadcase" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 10/06/1999
Posts: 5916
Loc: Wivenhoe, Essex, UK
|
Quote:
It's simply using the Karma protocol rather than the Empeg protocol.
If that is the case though, how is it that jEmplode quite happily discovers my empeg without help ? Surely if it is using the Karma protocol and only the Karama protocol it couldn't possibly discover my empeg ?
_________________________
Remind me to change my signature to something more interesting someday
|
|
Top
|
|
|
|
|
#288955 - 02/11/2006 13:31
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: andy]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
Quote:
It's simply using the Karma protocol rather than the Empeg protocol.
If that is the case though, how is it that jEmplode quite happily discovers my empeg without help ? Surely if it is using the Karma protocol and only the Karama protocol it couldn't possibly discover my empeg ?
Which exact version of jemplode.jar do you have? Filesize in bytes, please.
Thanks
|
|
Top
|
|
|
|
|
#288957 - 02/11/2006 14:51
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 10/06/1999
Posts: 5916
Loc: Wivenhoe, Essex, UK
|
I am using jEmplode 69.0000000000000000001 that I downloaded from the jempeg.org website today.
File size 1,969,173 bytes
Options are set only to Ethernet Broadcast, running on WinXP SP2.
_________________________
Remind me to change my signature to something more interesting someday
|
|
Top
|
|
|
|
|
#288958 - 02/11/2006 16:09
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: andy]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
I am using jEmplode 69.0000000000000000001 that I downloaded from the jempeg.org website today.
File size 1,969,173 bytes
Options are set only to Ethernet Broadcast, running on WinXP SP2.
Mmm. Looking inside jemplode.jar, one can see that the code seems to be present for both SSDP (karma) and "IDiscovery" (empeg?) -- so somehow it's choosing not to run the other protocol here. A network trace proves this point (no normal empeg discovery is ever attempted, only the SSDP crap).
What java version?
Thanks
|
|
Top
|
|
|
|
|
#288959 - 02/11/2006 16:24
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Quote:
Mmm. Looking inside jemplode.jar, one can see that the code seems to be present for both SSDP (karma) and "IDiscovery" (empeg?) -- so somehow it's choosing not to run the other protocol here. A network trace proves this point (no normal empeg discovery is ever attempted, only the SSDP crap).
Can you strace the java process, or is that just asking for trouble? Is the Jemplode host multi-homed?
Peter
|
|
Top
|
|
|
|
|
#288960 - 02/11/2006 17:01
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: andy]
|
carpal tunnel
Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
|
Just as another datapoint, ditto what Andy said on both jEmplode 69.0000000000000000001 and jEmplode 70. Also running XP SP2
_________________________
~ John
|
|
Top
|
|
|
|
|
#288961 - 02/11/2006 19:37
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 10/06/1999
Posts: 5916
Loc: Wivenhoe, Essex, UK
|
Quote:
What java version?
I have 1.4.2 on this machine, but I have 1.5.something on my other machine that also works.
I have rarely seen discovery not work with jEmplode, over a series of versions of jEmplode and Java. All of this on Windows.
_________________________
Remind me to change my signature to something more interesting someday
|
|
Top
|
|
|
|
|
#288962 - 02/11/2006 20:37
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
Can you strace the java process, or is that just asking for trouble? Is the Jemplode host multi-homed?
strace on it seems to work. I wonder what to look for inside the trace? "send", I suppose:
Code:
[pid 22137] sendto(5, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22137] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22137] sendto(5, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22137] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22137] sendto(5, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22137] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16) = 1
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.255.255.255")}, 16) = 1
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.255.255")}, 16) = 1
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.1.255")}, 16) = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16 <unfinished ...>
[pid 22144] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22144] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22144] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22144] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22144] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22144] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22145] <... sendto resumed> ) = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.255.255.255")}, 16 <unfinished ...>
[pid 22145] <... sendto resumed> ) = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.255.255")}, 16) = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.1.255")}, 16) = 1
Mmm.. well, the references to port 8300 are for the regular empeg discovery method. But for some reason it's not using a valid broadcast IP address for them. Hmmph.
Code:
eth0 Link encap:Ethernet HWaddr 00:11:43:7A:5A:B9
inet addr:10.0.0.14 Bcast:10.0.0.127 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1860566 errors:0 dropped:0 overruns:0 frame:0
TX packets:1570532 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1199584566 (1.1 GiB) TX bytes:470436122 (448.6 MiB)
Interrupt:19
|
|
Top
|
|
|
|
|
#288963 - 02/11/2006 20:56
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Ahh.. bingo. Something is causing it to parse /etc/hosts to try and find the local ip address. Why does it do such a silly thing? Dunno, but it does.
Of course, my machine just has the loopback entries there, since the actual IP address depends very much upon the whims of whichever DHCP server I'm connecting through.
Duh.
If I hardcode my current IP address in /etc/hosts, then it works, but that's not a great solution.
Cheers
|
|
Top
|
|
|
|
|
#288964 - 02/11/2006 20:57
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Ahh.. waitaminute.. there was a loopback entry in /etc/hosts for the local hostname.. delete that line completely and it also now works.
Yippie!
Thanks for suggesting the obvious, peter!
|
|
Top
|
|
|
|
|
#288965 - 03/11/2006 07:31
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Glad you got it working, though I'm still a bit confused. If this is a single-homed Linux box, the all-ones address should have worked. And reading /etc/hosts wouldn't tell it that your netmask was /25 as opposed to /8 or /24. So it'd be interesting to see what packets it's sending now that it works. It's almost as if it was successfully sending to the all-ones address, but saying "reply to 127.0.0.1" because that's what it thinks its IP address is, so the reply never went anywhere -- but in that case, Wireshark should have seen the outgoing packet.
Peter
|
|
Top
|
|
|
|
|
#288966 - 03/11/2006 13:37
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Quote:
Glad you got it working, though I'm still a bit confused. If this is a single-homed Linux box, the all-ones address should have worked.
I think Linux may be set to filter out anything that doesn't match the subnet -- but I'll check that again with the analyser shortly.
Quote:
And reading /etc/hosts wouldn't tell it that your netmask was /25 as opposed to /8 or /24.
Right. And yes indeed, it is just blindly attempting 8/16/24 bit subnet masks regardless.
So it'd be interesting to see what packets it's sending now that it works.
Code:
[pid 26117] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26117] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26117] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 26117] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 26117] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26117] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16) = 1
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.255.255.255")}, 16) = 1
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.255.255")}, 16) = 1
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.255")}, 16) = 1
[pid 26120] recvfrom(5, "id=10101984\nname=george", 4096, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.16")}, [16]) = 23
|
|
Top
|
|
|
|
|
#288967 - 03/11/2006 13:49
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Hmm.. it works (mostly), but is still flakey for some reason. Witness this: Code:
[pid 26183] bind(5, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.14")}, 16 <unfinished ...>
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16 <unfinished ...>
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.255.255.255")}, 16) = 1
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.255.255")}, 16) = 1
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.255")}, 16) = 1
[pid 26185] recvfrom(5, "id=10101984\nname=george", 4096, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.16")}, [16]) = 23
Another machine on the same *switch* saw only the 255.255.255.255 broadcast, along with the reply from george. I wonder where the other broadcast packets went to? [EDIT]Oh, wait.. the other packets were not valid broadcast addresses, so they either got dropped or just not delivered by the switch to the monitoring machine (nor to any of the empegs!).[/EDIT]Mmm.. I suppose I really have to use a hub rather than a switch to know for sure. But enough is enough. It works now (mostly). Cheers
Edited by mlord (03/11/2006 13:54)
|
|
Top
|
|
|
|
|
#288968 - 03/11/2006 13:52
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14496
Loc: Canada
|
Mmm.. I wonder of the nagle algorithm is getting in the way, or is that strictly just a TCP thing?
[EDIT] Scratch that. It all makes sense now in the edited post above. The 255.255.255.255 address is the only one that is actually working here, because of my 7-bit subnet.[/EDIT]
Edited by mlord (03/11/2006 13:55)
|
|
Top
|
|
|
|
|
#288969 - 03/11/2006 15:05
Re: JEmplode "ethernet broadcast" discovery protocol bug?
[Re: mlord]
|
addict
Registered: 11/11/2001
Posts: 552
Loc: Houston, TX
|
Something I've noticed on my linux box that I'm using for a router/NAT is that unless I put in a route for 255.255.255.255 to go out through the internal interface, it will go out the external interface due to the default route. I learned that one by dealing with xPL where all the hubs on the network talk to each other using the broadcast address.
_________________________
--Ben
78GB MkIIa, Dead tuner.
|
|
Top
|
|
|
|
|
|
Previous Topic
Index
